核心角色权限对比
| 权限 | Guest | Reporter | Developer | Maintainer | Owner/Admin |
|---|---|---|---|---|---|
| 查看项目 | ✅ | ✅ | ✅ | ✅ | ✅ |
| 创建 Issue | ❌ | ✅ | ✅ | ✅ | ✅ |
| 提交代码到非保护分支 | ❌ | ❌ | ✅ | ✅ | ✅ |
| 推送保护分支 | ❌ | ❌ | ❌ | ✅ | ✅ |
| 合并MR | ❌ | ❌ | ❌ | ✅ | ✅ |
| 修改项目设置 | ❌ | ❌ | ❌ | ✅ | ✅ |
| 删除项目 | ❌ | ❌ | ❌ | ❌ | ✅ |
关键分支保护规则
graph TD A[主分支 main/master] --> B[禁止直接推送] B --> C[必须通过 MR 合并] C --> D[需至少 1 人批准] D --> E[CI 流水线通过]
操作步骤
1、进入项目设置:
项目 → 设置 → 仓库 → 展开“保护分支”

2、配置保护规则:
main 或 production开发者可以发起合并请求,一般称之为MR(Merge Request)维护者+ (允许开发者发起 MR,但需维护者批准)维护者❌ 禁用 (防止历史被篡改)
3、通配符保护(需要批量设置前缀一致的分支的情况,和上面类似):
release/*开发者维护者维护者权限继承流程图
graph TD A[父群组: 公司领导层] -->|成员自动继承| B[子群组: 终端应用部] B -->|成员自动继承| C[项目: A] B -->|成员自动继承| D[项目: B]
批量管理步骤
1、创建群组:
2、分配组权限:
Developer (默认成员权限)Maintainer3、项目继承权限:
新建项目时选择所属群组,自动继承组权限
4、以成员管理为例具体演示:
父群组:
子群组:
子群组项目:
